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MEANS AND METHOD FOR SINGLE SIGN-ON ACCESS TO A 
SERVICE NETWORK THROUGH AN ACCESS NETWORK 

FIELD OF THE INVENTION 

[0001] The present invention generally relates to Single 
5 Sign-On services for a user accessing a service network of a 
network operator through an access network;, the user having 
been previously authenticated for accessing the access 
network by a core network of the network operator. More 
specifically, the invention relates to means and method for 
10 Single Sign-On authentication purposes in the above scenario. 



BACKGROUND 

[0002] A mobile network operator wanting to offer a Wireless 
Local Area Network (WLAN) access to its users likely wants to 
use SIM-based authentication procedures for this access, so 

15 that the users have a single security token, such as a SIM 
card may be, for different access technologies while 
maintaining a uniform level of security. A Wireless Local 
Area Network (WLAN) , where users of a mobile network operator 
may access through, is referred to as a WLAN access network. 

20 WLAN access protocol is generally governed by IEEE 802.11 
protocol specification. 

[0003] The WLAN access network itself may belong to a mobile 
network operator (hereinafter referred to as MNO) , or to some 
other operator such as a WLAN Internet Service Provider. 

25 Irrespective of the operator owning the WLAN access network, 
user authentication is traditionally performed in a core 
network (CN) of the MNO where the user holds a subscription 
(namely the MNO core network ,r and hereinafter abbreviated as 
MNO-CN) . An exemplary MNO-CN might be a GSM core network, a 

30 GPRS core network, or a UMTS core network, amongst others. 
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[0004] During the authentication of a user by an MNO-CN a 
number of entities are involved^ such as an Authentication 
Gateway (AG) receiving an access request originated by the 
user^ fetching authentication vectors (AV) for authenticating 
5 the user from a Home Location Register (HLR) , and granting 
access to the user once said user has been successfully 
authenticated. The Authentication Gateway (AG) generally 
authenticates a user through a challenge-response mechanism, 
such as the Authentication and Key Agreement (AKA) suggested 
10 in rfc3310 may be, though other authentication procedures may 
be applied as well. Apart from these entities, there is 
generally provided an Authentication Centre (AuC) entity in 
charge of generating authentication vectors for a number of 
users, and to be provided to the HLR upon request . 

15 [0005] In operation, once a user has gained access to the 
WLAN access network and has been thus authenticated, the user 
may try to gain e^oo^ss to services available in a service 
network (SN) , said service network (SN) may in particular 
belong to the mobile network operator (hereinafter referred 

20 to as MNO-SN) . At present, provided that the user accesses 
this MNO-SN through a WLAN access network, the user has to be 
authenticated by the MNO-SN even though the WLAN access 
network had already authenticated the user. For the sake of 
clarity, a descriptive distinction is worthwhile between an 

25 "^access level authentication'' and a ^^service level 
authentication' for a user. The former being the user 
authentication carried out by the core network (CN) before 
granting the user access to the access network, whereas the 
latter being the user authentication carried out by the 

30 service network (SN) before granting the user access to 
services in said service network. 

[0006] An exemplary teaching of this ^service level 
authentication'' carried out by a sort of service network is 
described in the University paper ^^Using GSM/UMTS for Single 
35 Sign-On'' by Andreas Pashalidis and Chris Mitchell, 
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Information Security Group, Royal Holloway University of 
London. In this paper, the main components are said to be a 
User System (US) consisting of a network access device, a SIM 
card and a SIM card reader; a Service Provider (SP) , which in 
5 the context of this paper is any entity that provides some 
kind of service or content to a user; and the GSM operator'' s 
Authentication Centre (AuC) . 

[0007] The University paper introduces a concept of Single 
sign-on (SSO) as a technique where users authenticate 

10 themselves only once to a trusted Authentication Service 
Provider (ASP) , and are automatically logged into the SPs 
they subsequently use, without necessarily having to re- 
authenticate each time. Under this SSO concept, an SP needs 
some form of notification from the ASP that indicates the 

15 user's authentication status. These notifications are termed 
authentication assertions . 

[0008] The proposal made in this University paper for SSO 
starts when the user requests a service from the SP. The 
process has a first step where the SP sends a random value 

20 (RAND) towards the US; a second step where the SIM in said US 
computes a ciphering key Kc as a function (GSM algorithm A8) 
of a secret user key Ki and the given RAND; a third step 
where the US computes another final code (MAC, SHA-1) using 
this ciphering key Kc on the SP identifier (SPID); a fourth 

25 step where the US returns back to the SP a user's identifier 
(IMSI) and the computed MACkc(SPID); a fifth step where the 
SP transmits this answer along with the RAND to the AuC; a 
sixth step where the AuC finds the secret user key Ki 
corresponding to the user's identifier (IMSI) and computes a 

30 ciphering key Kc as a function (GSM algorithm A8) of the 
secret user key Ki and the given RAND; a seventh step where 
the AuC also computes a MACkc(SPID) with the ciphering key Kc 
previously computed, and checks whether the received 
MACkc(SPID) matches the one lately calculated; and an eighth 

35 step where the AuC returns to the SP an authentication 
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assertion indicating a valid authentication of the user when 
the above matching occurs or an authentication failure 
otherwise. Now, the SP has got an authentication assertion so 
that further authentications are not needed under the SSO 
5 concept presented in this paper . 

[0009] A first teaching in this University paper is that an 
SP, namely ^^any entity that provides some kind of service or 
content to a user'' in its own wording, always triggers a sort 
of explicit and complete GSM authentication procedure, as 
shown in this paper, with the SP generating the RAND value, 
triggering the authentication procedure, and acting as an 
intermediate entity between the user equipment and the 
authentication entity of the home core network, the latter 
carrying out the explicit and complete GSM authentication 
procedure. The scenario in this University paper may be 
similar to the one described as initiating this description 
if a reader assumes the SP as an entity in the service 
network (SN) receiving service requests from users • 

[0010] However, even though this paper cites a WLAN access 
20 as a possible interconnection, nothing is described about a 
sort of previous "^access level authentication' of the user 
with its own mobile network- Moreover, assuming that the user 
is connected to the mobile network when accessing the SP, the 
user should have been previously authenticated by its mobile 
25 core • network before being granted such access. There is no 
description in this respect in the University paper, and the 
concept of SSO seems to apply only after having successfully 
authenticated the user at an SP, or at an entity of the 
service network. That is, the SSO seems to apply only after 
30 having carried out an explicit ^service level authentication' 
for the user. 

[0011] A second teaching of this University paper is that 
the authentication procedure may be carried out between the 
US and a UMTS/3GPP network, having the SP as an intermediate 
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entity transmitting the challenge from the AuC towards the 
US, and the response from the US towards the AuC, and finally 
receiving the authentication assertion from the AuC if the 
user had been successfully authenticated. As for the first 
5 teaching commented above, an explicit and complete 
authentication of the user is carried out at request from, or 
with participation of, the SP where the user has accessed. 

[0012] There is, however, no teaching in this Paper in 
respect of applying SSO for a user who had been authenticated 

10 before, when accessing other network or other network domain. 
In particular, there is no teaching on whether a user had 
carried out a previous ^access level authentication'' through 
an access network such as WLAN, and there is no teaching on 
how this ^access level authentication'' may be re-used as a 

15 further ^service level authentication'' when accessing the 
service network within a broader SSO principle. 

[0013] Moreover, even though the University paper states 
that a user authenticates only once to a trusted 
Authentication Service Provider (ASP) and is automatically 

20 logged into the Service Provider that the user further uses, 
there is no enabling disclosure of how this can be carried 
out. In this respect, the paper only cites that the AuC and 
the US need to agree on the use of a Message Authentication 
Code (MAC) function, which is further used to compute a 

25 MACkc(SPID) submitted from the SP to the AuC for checking 
whether the user had been authenticated. In accordance with 
the teaching in "Applied Cryptography", by Bruce Schneier, 
ISBN 0-471-11709-9, a message authentication code (MAC) , also 
known as a data authentication code (DAC) , is a one-way hash 

30 function acting on an input with the addition of a secret key 
(Section 18.14), wherein a one-way means that there is no 
manner to derive the inputs to the function from the output 
and thus there is no means for verifying that a user had been 
already authenticated other than repeating the authentication 

35 mechanism and comparing the result offered with the one 
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received. Thereby, there is no applicable teaching in this 
University paper for re-using a previous access level 
authentication when accessing the service network. 
Furthermore, if the user attempts to access a service in a 
second SP, said second SP having a different SPID, the 
previous complete explicit authentication would have to be 
repeated again to produce a new MACkc(SPID) for said 
different SPID, since the previous assertion stored in the 
first SP does not seem to be known and applicable to the 
second SP. 

[0014] In this context. Single Sign-On (SSO) is for the 
purpose of the present invention an emerging principle that 
enables users to access different networks, or different 
network domains, without explicitly authenticating such users 
for each particular different network, or different network 
domain, once the users had been already authenticated. This 
principle implies that a user is authenticated only once at a 
given network, or given network domain, and the resulting 
authentication is valid for entrance to other networks, or 
network domains. In other words, the purpose of SSO is to 
allow users to securely access different networks and network 
domains, without being explicitly authenticated every time. 

[0015] A special case occurs when a same entity^ for example 
a mobile network operator (MNO) , fully controls the access 
level authentication, wherein the user has been authenticated 
with the core network (CN) of the MNO, and the MNO may trust 
on this authentication to allow the user further accessing to 
the service network (SN) of the MNO. For instance, a user may 
be authenticated with the MNO-CN in order to gain access to a 
General Packet Radio Service (GPRS) from where the MNO-SN is 
accessible, and the MNO-SN relies on this authentication 
since the GPRS network is a trusted network from the mobile 
network operator perspective. 



wo 2005/064882 



7 



PCT/EP2003/014978 



[0016] More specifically^ and illustrative for the known 
GPRS technique commented above^. when a user has gained access 
to the MNO core network (MNO-CN) through a GPRS access 
network and has been thus authenticated^ the user is assigned 
an IP address that is trustable^ since all equipment in the 
IP infrastructure of the mobile network operator is supposed 
to have anti-spoof ing capabilities in order to prevent the 
malicious use of fake IP addresses. That is^ the IP address 
assigned to the user can be used to track that the user 
having accessed to the MNO core network (MNO-CN) is the same 
as the one now accessing the MNO service network (MNO-SN) . 
This identification is notified by a Gateway GPRS Support 
Node (GGSN) to an entity in the MNO service network, such as 
an Authentication-Authorisation-Accounting (AAA) server. In 
short,, the assignation of an IP address by the MNO core 
network (MNO-CN) to identify an authenticated user is a key 
aspect of the SSO solution for a typical MNO service network 
accessed through a trusted access network such as a GPRS 
network. 

[0017] Under this special case, the MNO service network 
(MNO-SN) can only rely on the MNO core network (MNO-CN) 
authentication if the access network, which the user is 
accessing through, provides data origin authentication. This 
is the case, for example, when the user is accessing through 
a GPRS access network. In this context, data origin 
authentication means that for any data received from the 
access network, such as the above IP address that the user is 
assigned, the claimed originator of said data can be 
considered authentic, irrespective of the originator. 

[0018] However, a WLAN access network is not able to assign 
IP addresses in a trustable way for the MNO, since the WLAN 
infrastructure usually does not belong to the MNO, and the 
anti-spoof ing capabilities presently existing in a GPRS 
access network cannot be expected to be available in a WLAN 
access network. Consequently, an IP address assigned to an 
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authenticated user and received at an MNO service network 
(MNO-SN) from a WLAN access network cannot be accepted as a 
token to track the presence of said user in the MNO service 
network and, hence, the traditional mechanism to support SSO 
authentication cannot be used. 

[0019] At this stage, attention is called to the University 
paper commented above wherein no mention appears in respect 
of re-using or trusting a possibly previous access level 
authentication of the user with its own core network while 
likely accessing the serving entity (SP) , namely accessing an 
entity in the service network, through a WLAN access network. 

[0020] The present invention is aimed to provide means and 
method for offering a broader Single Sign-On mechanism to 
users of a mobile network operator when the users are 
accessing a service network through a non-trusted access 
network, said users having been previously authenticated by 
the core network of the mobile network operator. 

[0021] Moreover, this aim also ambitions to make this means 
and method for offering the broader Single Sign-On mechanism 
also applicable to users of a fixed network operator under a 
single inventive concept. 

[0022] Therefore, an object of the present invention is the 
provision of an SSO mechanism that allows the service network 
to trust on an authentication token received through a non- 
trusted access network and intended to prove that a user had 
been previously authenticated. 

[0023] It is a further object of the present invention that 
this SSO mechanism may also be used where the access network 
is a fully trusted access network so that distinguishing 
whether an access network may or may not be trusted by the 
service network becomes a superfluous discussion. 
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SUMMZ^Y OF THE INVENTION 

[0024] The above aim is accomplished in accordance with the 
present invention by the provision of the apparatus of claim 
1, the session manager of claim 4 coupled with the apparatus 
5 of claim 8, the user's equipn;Lent of claim 17, and the method 
of claim 21, all arranged for providing users a SSO access to 
a service network through an access network where users have 
been authenticated by a core network where they hold a 
subscription . 

10 [0025] The apparatus of claim 1, which is called 
Authentication Gateway in the instant specification, is in 
accordance with the invention arranged for receiving an 
access request in a telecommunication core network from an 
entity in an access network where a user with a user^'s. 

15 equipment accesses through. The user is subscriber of the 
telecommunication core network and identified by a user's 
identifier included in the access request. Such an apparatus 
generally comprises : 

— means for carrying out an authentication procedure with 
20 the user's equipment through the access network in order 

to authenticate the user; and 

— means for computing at least one secret user's key (Kc) 
usable as cryptographic material; 

[0026] This Authentication Gateway comprises in accordance 
25 with the invention: 

— means for deriving from the cryptographic material a 
user's shared key intended for SSO purposes; and 



30 



— means for sending said user' s shared key along with the 
user's identifier towards a session manager serving a 
service network. 
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E0027] The Authentication Gateway preferably comprises means 
for being notified that a session at the access level has 
been established;, namely an access session, this notification 
triggering the sending of the user' s shared key towards the 
session manager serving a service network. Moreover, this 
Authentication Gateway may preferably comprise means for 
being notified that a session at the access level has been 
terminated, and means for forwarding this notification 
towards the session manager serving the service network in 
order to inactivate a current master session for the user. 

[0028] The session manager of claim 4 is an entity serving a 
service network for SSO purposes and arranged for managing a 
session record for a user accessing the service network 
through an access network. For the purpose of the present 
invention, the user has been previously authenticated by a 
telecommunication core network where the user holds a 
subscription . 

[0029] The session manager in accordance with the invention 
also comprises: 

— means for receiving a first user''s shared key and a user's 
identifier from the core network for SSO authentication 
purposes, this first user's shared key obtainable during 
the authentication of the user by the core network; 

— means for creating a master session for the user that 
comprises the user's identifier and the received first 
user's shared key; and 

— means for checking whether a second user' s shared key 
derived at the user's equipment matches the first user's 

. shared key included in the master session for the user. 

[0030] The session manager may advantageously include means 
for creating a service session to index the master session, 
in case of matching first and second user's shared keys, this 
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service session intended as a token of a successful SSO user 
authentication. Moreover;, this session manager may further 
include as well means for verifying whether a service session 
indexes an active master session for a user, in order to 
determine if a previous SSO authentication is still valid. 

[0031] Additional advantages may be obtained by providing a 
session manager wherein the means for checking, whether a 
second user's shared key derived at the user''s equipment 
matches the first user'' s shared key included in the master 
session, comprises means for processing the first user'^s 
shared key to obtain a first key code to be matched against a 
second key code originated from the user's equipment. 

[0032] In operation, the above session manager co-operates 
with the apparatus of claim 8, which is called in this 
instant specification Service Access Authentication Node. The 
distribution of features between the above session manager 
and this apparatus of claim 8 is rather based on the current 
trends and standards though other arrangements between this 
couple may be implemented, as further indicated in the 
preferred embodiments section. 

[0033] Such apparatus of claim 8 is intended for receiving a 
request from a user accessing a telecommunication service 
network through an access network with a user's equipment, 
once the user has been already authenticated by a 
telecommunication core network where the user holds a 
subscription, the request traditionally includes a user's 
identifier to identify the user. This apparatus comprises in 
accordance with the invention: 

— means for verifying whether an active service session is 
indicated in the request from the user's equipment; 

- means for assessing that a user's shared key is stored in 
the user's equipment; and 
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- means for determining in co-operation with the above 
session manager^ which is serving the service network for 
SSO purposes,, whether the user^s shared key at the user'^s 
equipment matches the one stored in the master session for 
said user. 

[0034] This apparatus preferably also comprises means for 
obtaining a service session for a user from the session 
manager serving the service network for SSO purposes - 
Moreover,. the apparatus may further include means for 
generating an SSO cookie to be submitted to the user's 
equipment, this SSO cookie comprising the service session. 
Further, the apparatus may also comprise means for receiving 
an SSO cookie from the user'' s equipment, the SSO cookie 
indicating a service session for the user. 

[0035] Additional advantages may be obtained by providing 
the apparatus with means for downloading an SSO plug-in 
towards the user's equipment, the SSO plug-in running for 
confirming back the user's shared key. 

[0036] Still further advantages may be obtained by providing 
an apparatus wherein the means for assessing that a user' s 
shared key is stored in the user's equipment includes means 
for receiving from the user's equipment an element selected 
from: 

— a key code obtainable by processing the user's shared key 
at the user's equipment; and 

— the user's shared key. 

[0037] This latest advantage cited above may be enhanced if 
the apparatus further comprises means for submitting the 
received element to the co-operating session manager serving 
the service network for SSO purposes. 
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[0038] Different scenarios may turn up as natural fields 
where the invention, in general, and this apparatus coupled 
to the session manager, in particular, may be applied. 

[0039] For instance, this apparatus may be used as an HTPP 
5 Proxy receiving service requests from users accessing a 
service network in a Walled-Garden SSO model - 

[0040] Also for instance, this apparatus may be used as an 
authentication node of an Identity Provider where a 
credential request is received from a user accessing a 
10 service of a Service Provider in a Federated SSO model. 

[0041] In order to effectively carry out the objects of the 
invention, there is provided a user^'s equipment according to 
claim 17. A user's equipment conventionally usable by a user 
with a subscription in a telecommunication network, is 
15 arranged to access a telecommunication service network 
through an access network, and includes: 

— means for carrying out an authentication procedure to 
authenticate the user with a core network, where the user 
holds the subscription, through the access network; and 

20 — means for computing at least one secret user'' s key usable 
as cryptographic material, such as a ciphering key for 
encryption purposes, amongst other keys. 

[0042] The user''s equipment in accordance with the invention 
also comprises: 

25 — means for deriving from the cryptographic material a 
user's shared key intended for SSO purposes; 

— a repository for storing the user's shared key; 



— means for confirming the user's shared key stored at the 
user's equipment towards an entity in the service network. 
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[0043] Additional advantages, as those described above for 
other entities, can be obtained by providing a user's 
equipment wherein the means for confirming the user'' s shared 
key stored at the user'' s equipment includes means for 
5 downloading an SSO plug-in from an entity in the service 
network, the SSO plug-in running for confirming back the 
user^s shared key. 

[0044] Moreover, additional security can be ensured by 
providing a user' s equipment wherein the means for confirming 
10 the user's shared key stored at the user's equipment includes 
means for processing the user's shared key to obtain a key 
code to be transmitted to an entity in the service network. 

[0045] In order to simplify further subsequent accesses of 
the user to the service network within the SSO mechanism in 
15 accordance with the invention, the user's equipment further 
comprises means for receiving an SSO cookie from an entity in 
the service network during the first access. This SSO cookie 
intended to be included in all further service requests from 
the user's equipment as an SSO token. 

20 [0046] Apart from the above means describing the structural 
part of the invention, there is also provided a method for 
supporting Single Sign-On services for a user with a user' s 
equipment arranged for accessing a telecommunication core 
network and service network through an access network. The 

25 user being identified as subscriber of the telecommunication 
core network when accessing the access network, and the 
method traditionally comprising the steps of: 

— carrying out an authentication procedure for the user 
between the core network and the user's equipment; 

30 — computing at an entity of the core network at least one 
secret user's key usable as cryptographic material; and 
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— computing at the user*^ s equipment at least one secret 
user's key usable as cryptographic material. 

[0047] The method, in accordance with the invention, also 
includes the steps of: 

5 — deriving a first user''s key intended for SSO purposes from 
the cryptographic material at an entity of the core 
network; 

— deriving a second user' s key intended for SSO purposes 
from the cryptographic material at the user's equipment; 

10 — creating a master session for the user at an entity in the 
service network, the master session comprising a user' s 
identifier and the first user's key; 

— confirming the second user' s shared key stored at the 
user' s equipment towards the entity in the service 

15 network; 

— verifying whether the second user's shared key matches the 
first user's shared key for the user at the entity in the 
service network; and 

— granting access to the requested service in the service 
20 network on matching the first and second user's shared 

keys . 

[0048] Additional advantages can be obtained by providing 
this method in such a manner that the step of verifying the 
matching of the first and second user' s shared keys further 

25 includes a step of creating a service session to index the 
master session, this service session intended as a token of a 
successful SSO authentication. Moreover, this method may 
further include a step of generating an SSO cookie to be 
submitted to the user's equipment, the SSO cookie comprising 

30 the service session. Furthermore, the method may further 
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comprise a step of verifying whether an active service 
session is indicated in the request from the user'^s equipment 
by examining whether an 330 cookie is received. 

[0049] In order to allow additional advantages on the 
5 provision of a usable user''s equipment^ the method is 
enhanced if the step of confirming the second user' s shared 
key stored at the user's equipment includes a step of 
downloading an SSN plug-in from an entity in the service 
network^ said SSO plug-^in running for confirming back the 
10 user's shared key. 

[0050] As cited above^. additional security can be ensured by 
providing a method wherein the step of confirming the second 
user's shared key stored at the user's equipment, includes a 
step of processing the user's shared key to obtain a key code 

15 to be transmitted to an entity in the service network. This 
method being more efficient if the step of verifying whether 
the second user's shared key matches the first user's shared 
key includes a step of processing at an entity of the service 
network the first user's shared key to obtain a first key 

20 code to be matched against a second key code originated from 
the user's equipment. 

[0051] Preferably, the method is carried out in such a 
manner that the step of creating a master session for the 
user at the entity in the service network includes a step of 
25 receiving the first user's key from an entity of the core 
network. 

[0052] Moreover, an advantageous implementation may be 
achieved if the step of creating a master session for the 
user at the entity in the service network includes a step of 
30 initiating an access session when the user accesses the 
access network. 
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BRIEF DESCRIPTION OF DRAWINGS 

[0053] The features^ objects and advantages of the invention 
will become apparent by reading this description in 
conjunction with the accompanying drawings in which: 

5 [0054] FIG. 1 presents a basic diagram showing the entities 
and main interfaces involved to carry out an SSO 
authentication when a user with a user's equipment accesses a 
service network via a WLAN access network, the user having 
been authenticated before by the core network where the user 
10 holds a subscription. 

[0055] FIG. 2A illustrates the sequence of actions carried 
out by a user's equipment accessing the core network (CN) 
where the user holds a subscription through a WLAN access 
network in order to be authenticated by said core network. 

15 [0056] FIG. 2B illustrates the sequence of actions carried 
out by a user's equipment accessing a service network (SN) 
through an access network (WLAN) once the user had been 
authenticated by the core network as shown in Fig. 2A. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

20 [0057] The following describes some preferred embodiments 
for offering a Single Sign-On mechanism to users of a network 
operator when accessing a service network (SN) of the network 
operator through an access network, such as a WLAN access 
network,, wherein said users had been previously authenticated 

25 by the core network (CN) of the network operator. 

[0058] The present invention presents several aspects in 
connection with the mechanism carried out between user 
equipment (UE) and different entities at the core network 
(CN) and at the service network (SN) of a network operator. 
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[0059] For the purpose of the present invention;- a user 
equipment (UE) is a terminal which may be an integral device 
or a number of interconnected devices, arranged for accessing 
a network where the user holds a subscription and for 
5 accessing another access network such as a WLAN network; the 
user' s equipment comprising an access authentication client 
responsible for carrying out an authentication procedure at 
the user side with a core network (CN) of the network where 
the user holds tine subscription, and a web browser also 
10 called user client and responsible for accessing services in 
a service network (SN) . Cryptographic material is generated 
at the user side by the access authentication client during 
this access level authentication procedure to be further used 
in accordance with the present invention. 

15 [0060] In particular, said network where the user holds a 
subscription may toe a mobile network. In that case, the 
access level authentication is preferably carried out by a 
SIM-based authentication procedure. Therefore, the user's 
equipment also comprises a SIM card with subscription data 

20 along with a SIM card reader. 

[0061] On the other hand, said network where the user holds 
a subscription might also be a fixed network, in which case 
the user' s equipment may be configured depending on the 
particular authentication procedure that the operator wants 

25 to be carried out by the access authentication client. As for 
a mobile network, the authentication procedure between a user 
and a fixed network may be pos.sibly based on the use of a 
particular user card with relevant subscription data, and the 
user's equipment thus including a corresponding card reader; 

30 or it may be possibly based on the use of a user' s identity 
and a user's password, where the cryptographic material may 
be generated from said couple of user' s identity and a user' s 
password . 
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[0062] An interesting advantage of having a separable card 
reader from the user' s equipment, in case the authentication 
procedure is SIM-based or the like;^ is that once the user has 
been authenticated by the core network (CN) , and for SSO 
5 purposes in accordance with the invention, the card can be 
extracted and the card reader disconnected during further 
establishment of a service session with the service network. 

[0063] In short and illustrated in Fig. 1^ the object of the 
invention is achieved by authenticating a user at access 

10 level, for instance at the WLAN access network, thanks to an 
authentication procedure carried out by using core network 
(CN) infrastructure. This core network, as above commented, 
may be a mobile network or a fixed network depending on the 
appropriate choice of an applicable authentication procedure 

15 and corresponding protocol. Nevertheless, and for the sake of 
simplicity, most of the embodiments dealt with throughout 
this description refer to a mobile network operator (MNO) for 
illustrative purposes and without aiming to restrict the 
scope of the invention to such mobile network environment . 

20 [0064] During this authentication procedure, a shared key 
(SSO_key-l; SS0_key-2) is respectively derived from 
cryptographic material obtainable from the authentication 
procedure between an Authentication Gateway (AG) at the core 
network (CN) and the user's equipment (UE) . This shared key 

25 is, on an immediate step, stored (SS0_key-2) at the user's 
equipment (UE) and, on a further step, submitted (SSO__key-l) 
from the Authentication Gateway (AG) towards an entity 
serving the service network (SN) for SSO purposes, such 
entity called Session Manager for SSO (SSO_SM) in this 

30 instant specification, and responsible for managing session 
records for users who had carried out a successful 
authentication procedure with the core network (CN) . The 
shared key (SSO_key-2) stored at the user's equipment (UE) is 
further included in a first service request message, and 

35 intended to be an authentication token when the user access 
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the service network (SN) r said token being checked versus the 
corresponding one (SSO_key-l) stored in the Session Manager 
for SSO (SSO_SM), so that a new explicit user authentication 
at the service network (SN) is not required. 

5 [0065] In accordance with a first aspect of the present 
invention,, there is provided a currently preferred embodiment 
to achieve a SIM-based authentication for a WLAN user through 
an authentication procedure with the core network (CN) . 

[0066] Therefore and as shown in Fig. 2A, a user's equipment 
10 (UE) establishes an 802.11 association (S-21) with an Access 
Point (AP) , the association including a user''s identifier 
that allows further identification of the user by the core 
network (CN) . An Access Point (AP) in a WLAN network 
generally enforces an access control and^ given that RADIUS 
15 is a protocol suitable within both WLAN and core network (CN) 
infrastructures^ the Access Point (AP) acts as RADIUS client 
towards said WLAN infrastructure. In this respect other 
protocol arrangements such as Diameter may be used instead of 
RADIUS without significant differences for the purpose of the 
20 present invention . 

[0067] Thus, a RADIUS access request including the user''s 
identifier is sent (S-22) to a RADIUS server or RADIUS proxy 
belonging to the WLAN infrastructure, such as a so-called 
WLAN Access Server (WLAN -AS) . This WLAN Access Server (WLAN- 
25 AS) may perform authentication for local users, thus acting 
as a RADIUS server, and is an edge entity acting as a RADIUS 
proxy for communication with the core network (CN) , the 
latter responsible for triggering the authentication for the 
user - 

30 [0068] The WLAN Access Server (WLAN~AS), as detecting that 
the user is subscriber of a Mobile Network Operator (MNO) , 
forwards (S-23) the access request towards an Authentication 
Gateway (AG) located at the MNO core network (CN) . 
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[0069] The Authentication Gateway (AG) in the MNO core 
network^ which may be acting as a RADIUS server^ is arranged 
for carrying out a sort of SIM-based authentication at the 
network side. Therefore, the AG obtains (S-24) a niomber of 
5 Authentication Vectors (AV) from a Home Location Register 

(HLR) r such Authentication Vectors likely generated in a 
dedicated Authentication Centre (AUG) not relevant for the 
purpose of the present invention. 

[0070] Then, the AG initiates (S-25) a challenge-response 
10 authentication procedure with the user's equipment (UE) by 
making use of these Authentication Vectors. 

[0071] The authentication procedure might be based on an 
Extended Authentication Protocol (EAP) , generally known as an 
EAP-based authentication, where the access authentication 
15 client (WLAN-Client) at the user's equipment (UE) is acting 
as an EAP-client and the Authentication Gateway (AG) as an 
EAP-server . 

[0072] During a conventional authentication procedure (S-25) 
or, more precisely, upon a successful response from the 

20 user's equipment (UE) to the challenge, the Authentication 
Gateway (AG) sends a RADIUS Access Accept (S-26, S-27) 
message to the RADIUS client (AP) , said message transporting 
an EAP-Success for the access authentication client at the 
user's equipment (UE) . The RADIUS client (AP) in turn grants 

25 (S-28) the user access to the WLAN access network, 

[0073] In accordance with a preferred embodiment, and after 
having carried out the authentication procedure, the present 
invention proposes that both user's equipment (UE) and 
Authentication Gateway (AG) , following a shared mechanism, 
30 respectively derive (S-252; S-251) on their own a shared key 
(SS0_key-2; SSO^key-l) for the user, from the cryptographic 
material obtained as computing a response to the 
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authentication challenge between the Authentication Gateway 
(AG) and the user's equipment (UE) . 

[0074] For instance, during the authentication procedure 
explained above when discussing the prior art, a ciphering 
5 key (Kc) was obtained for further ciphering purposes. This 
ciphering key (Kc) , as well as other keys obtainable by 
carrying out an authentication procedure, can be considered 
as the cryptographic material from where a shared key 
(SS0_key-2; SSO_key~l) for the user can be computed at both 
10 user'' s equipment (UE) and Authentication Gateway (AG). 

[0075] Thus, a first shared key (SSO_key-l) computed at the 
Authentication Gateway (AG) is stored therein in order to be 
further provided towards the service network (SN) , whereas a 
second shared key (SS0__key-2) computed at the user^'s 
15 equipment (UE) is stored in said user's equipment along with 
the user's identifier relevant for the access. 

[0076] Preferably, the shared key (SS0_key"2) is stored in a 
repository of the user's equipment accessible to other 
applications. If the user's equipment so permits, a registry 
20 of the operating system may be a suitable repository to this 
end provided that, on the one hand, such registry offers 
enough security and, on the other hand, such registry offers 
an easy identification of the shared key to allowed 
applications . 

25 [0077] Alternatively, an access authentication client (WLAN- 
client) , shown in Fig. 1, might as well act as repository to 
keep locally stored the shared key and user' s identifier for 
the user, and to make them available to other allowed 
applications via an Application Programming Interface (API) . 

30 [0078] Moreover, additional security means may be provided 
in accordance with the invention to ensure that the access to 
the shared key (SS0_key-2) at the user's equipment is only 
allowed for a certain number of applications, plug-ins or 
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pieces of software recognizable at the repository in order to 
prevent that malicious software;, such as a Trojan software;- 
could get access to said shared key to be further used as an 
authentication token . 

5 [0079] Once the access level authentication has taken place 
with an authentication procedure carried out between the 
access authentication client at the user's equipment (UE) and 
an Authentication Gateway (AG) at the core network (CN) , the 
user is granted access {3-26^ 3-21, S-28) to the WLAN access 

10 network. At this stage,. the Authentication Gateway (AG) 
receives a RADIUS accounting start message (S~29) initially 
intended to indicate that the user has initiated a session 
with the WLAN access network, namely an access session. This 
message includes a user''s identifier, and ends the sequence 

15 shown in Fig. 2A where the user accesses via an access 
network (WLAN) after having been authenticated by the core 
network (CN) where the user holds a subscription. The 
Authentication Gateway (AG) is noticed the end of an access 
session with the reception of a RADIUS accounting stop 

20 message, which is not shown in any drawing. 

[0080] As shown in Fig. 2B, when an access session has been 
initiated (S-2 9) with the WLAN access network, the 
Authentication Gateway (AG) forwards this RADIUS accounting 
message (S-30), after having included in the message said 
25 shared key (SSO_key-l) for the user, towards an entity 
serving the MNO service network (MNO-SN) for SSO purposes, 
namely the Session Manager for SSO (SSO_SM) , and which is 
responsible for managing session records for users who had 
carried out a successful authentication 

30 [0081] The Session Manager for SSO (SSO_SM) then creates a 
session record (S-301) for the user, which is called master 
session throughout this instant specification, where both 
user'' s identifier and shared key (SSO__key-l) for the user are 
stored as information of the access session. The Session 
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Manager for SSO (SSO_SM) maintains this master session until 
receiving a RADIUS accounting stop message initially received 
in^ and forwarded from;, the Authentication Gateway (AG) to 
indicate the end of the session^- what is not shown in any 
5 drawing. 

[0082] At this stage the service network (SN) is ready for 
accepting the user access under an SSO authentication. There 
are two scenarios where particular aspects of the invention 
are further described. 

10 [0083] In a Walled-Garden SSO model, namely in a scenario 
where an environment such as a mobile network operator (MNO) 
controls the user access to web content and services, the 
user tries to access a service or application belonging to, 
or controlled by, the mobile network operator where the user 

15 holds a subscription. To do so, a web browser at the user's 
equipment (UE) sends an HTTP service request (S-31) towards 
an HTTP Proxy (SAAN) in the MNO service network (MNO-SN) . In 
accordance with an aspect of the present invention, a Service 
Access Authentication Node (SAAN) is provided in the service 

20 network (SN) to act as an HTTP Proxy in a Walled-Garden SSO 
model with new features according to, and for the purpose of, 
the invention as illustrated in Fig. 1 and Fig. 2B. 

[0084] On the other hand, in a Federated SSO model where a 
mobile network operator (MNO) acts as an Identity Provider 

25 responsible for authenticating users and authorising services 
offered to its users by a number of Service Providers bound 
by contractual service agreements to the Identity Provider 
and thus forming a ^^circle of trust"', the user tries to 
access a service or application belonging to one of said 

30 Service Providers. Therefore, this Service Provider must be 
federated with the MNO, and the service or application may 
preferably offer an option to perform SSO with the MNO acting 
as Identity Provider. In accordance with the invention, when 
the user chooses this option, a web browser in the user''s 
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equipment (UE) is re-directed (S-31) to an authentication 
node of the Identity Provider (SAAN) in order to get a user 
credential indicating that the user has been authenticated. 
In accordance with another aspect of the present invention^, a 
5 Service Access Authentication Node (SAAN) is provided in the 
service network (SN) to act as the authentication node of the 
Identity Provider in a Federated SSO model with new features 
according to, and for the purpose of, the invention as 
illustrated in Fig- 1 and Fig. 2B. 

10 [0085] Thereby, a Service Access Authentication Node (SAAN) 
represents hereinafter an HTTP Proxy receiving a service 
request (S-31) from a user in a Walled-Garden SSO model, or 
an authentication node of the Identity Provider receiving a 
credential request from a user in a Federated SSO model, as 

15 the case might be. 

[0086] The Service Access Authentication Node (SAAN) may 
trigger (S-32) an SSO plug-in download towards the user's 
equipment (UE) - This step is only necessary the very first 
time the user accesses the service network (SN) since an SSO 

20 authentication procedure is required. That is, once the SSO 
plug-in is available at the user's equipment, there is no 
need to download it again. In a currently preferred 
embodiment,, when a user tries to access any service for the 
first time^ the Service Access Authentication Node (SAAN) 

25 notices there is no service session already established at 
service level for that user. For example, the Service Access 
Authentication Node (SAAN) can notice this by the absence of 
an SSO cookie that will be further explained when the service 
has been granted within an SSO authentication. In that case, 

30 the Service Access Authentication Node (SAAN) initiates the 
establishment of a session at service level before granting 
access to the service. This may comprise a number of steps 
wherein a first step is the download of the SSO Plug-in to 
the user equipment if it has not been downloaded before - 

35 Then, a second step of communicating with the SSO Plug-in, 
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which is running in the user equipment, in order to assess 
that a shared key (SS0_key-2) is available at the user'' s 
equipment, confirming that the user has been previously 
authenticated at access level. 

5 [0087] Alternatively and not shown in any drawing, a certain 
piece of software may be included in the user's equipment 
with an equivalent functionality as provided by the above SSO 
plug-in. 

[0088] The SSO plug-in, or the alternative piece of 

10 software, is responsible for obtaining the shared key 
(SSO key-2) for the user from the repository where it is 
stored at the user's equipment (UE) along with the user's 
identifier, and is responsible for communicating (S-33) with 
the Service Access Authentication Node (SAAN) in order to 

15 carry out an SSO authentication. Therefore, the SSO plug-in 
is arranged for submitting said shared key (SS0_key-2) for 
the user towards the Service Access Authentication Node 
(SAAN) . Different alternatives are provided for submitting 
said shared key (SS0_key-2), one the one hand, the shared key 

20 may be submitted as such, or encrypted; and, on the other 
hand, the shared key (SS0_key-2) may be processed to obtain 
another key code (MAC (SS0_key-2) ) to be submitted instead. 
The process of obtaining the key code might be a MAC or 
another internal function shared with the service network 

25 (SN) - This SSO authentication simply implies the recognition 
that the user had been previously authenticated by a core 
network (CN) when the user requested access to the WLAN 
access network - 

[0089] During this SSO authentication process, the Service 
30 Access Authentication Node (SAAN) communicates with the 
Session Manager for SSO (SSO_SM) in order to address the 
corresponding shared key (SSO_key-l) stored at the master 
session for the user, who is identified by the same user's 
identifier that was used for the access (WLAN) level 
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authentication^, and to check that the user has an active 
master session. 

[0090] At this stage^ it is noticed that the Session Manager 
for SSO (SSO_SM) might be an integral part of the Service 
5 Access Authentication Node (SAAN) r so that a mere local 
communication takes place between different software or 
hardware elements at the couple formed by the Service Access 
Authentication Node (SAAN) and the Session Manager for SSO 
(SSO_SM) - Other alternative embodiment might be preferred 

10 where the Session Manager for SSO (SSO_SM) receives from the 
Service Access Authentication Node (SAAN) the shared key 
(SSO_key-2) received from the user's equipment^. checks 
whether this shared key (SSO_key-2) matches the one stored in 
the master session (SSO_key-l) , namely the one received from 

15 the Authentication Gateway (AG) after valid authentication by 
the core network (CN) , and sends back an SSO authentication 
result to the Service Access Authentication Node (SAAN) 
indicating a valid authentication in case of matching. In 
particular, when the Service Access Authentication Node 

20 (SAAN) has received a key code (MAC (SS0_key-2) ) from the 
user'' s equipment, instead of the user's shared key (SS0_key- 
2), the former is passed to Session Manager for SSO (SS0_SM) 
where,, by applying a same process as in the user' s equipment 
to the shared key (SSO_key~l) stored in the master session, a 

25 corresponding key code (MAC (SSO_key-l) ) is obtained to be 
matched against the one received from the user's equipment. 

[0091] At this stage, in case of matching, a service session 
is created to index the corresponding master session and 
including data relevant for accessing the service. A service 

30 session may be regarded as a reference indexing the master 
session for the user, and a number of service related data, 
which in particular may be stored within the master session - 
The existence of a service session for a user is interpreted 
as a proof that the user has successfully passed an SSO 

35 authentication within the service network. This service 
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session may be submitted towards the user'' s equipment in 
order to be further included by the user's equipment in all 
subsequent service requests. The service session may be 
submitted in different ways, for example, as an SSO cookie 
5 complying with standard cookies used for HTTP protocol 
session handling. This SSO cookie comprising the service 
session, which is considered enough information to index the 
user''s master session in accordance with the invention,. 

[0092] Once the user has been authenticated, the Service 
10 Access Authentication Node (SAAN) , or the Session Manager for 
SSO (SSO__SM) , depending on the different above embodiments, 
can enable the user to access the requested service (S~35, S~ 
36, S-37) in a sort of Walled-Garden model, or can provide 
the requested credential to the user in a sort of Federated 
15 model- Moreover, either of these coupled entities, the 
Service Access Authentication Node (SAAN) and the Session 
Manager for SSO (SSO_SM) , may preferably place the SSO cookie 
in the browser of the user's equipment so that during 
subsequent service or credential requests the only check to 
20 perform is that the SSO cookie is there, thus precluding 
ulterior implicit authentication processes based on the 
shared key (SSO_key-l, SS0_key-2) , since the service session 
can be obtained from the SSO cookie, and the master session 
indexed thereof. 

25 [0093] In this respect, it has to be noticed that the shared 
key (SSO_key-l, SS0__key-2), having been derived from a 
cryptographic material obtained during the explicit 
authentication process carried out between the user''s 
equipment (UE) and the core network (CN) , is intended to be 

30 used just once, and any further use of the same shared key 
will be rejected by an entity of the coupled Service Access 
Authentication Node (SAAN) and Session Manager for SSO 
(SSO SM) . 



